FIG. 1 shows an example of a roaming Mobile Node MN such as a possibly multi-homed portable telephone with General Packet Radio Service (GPRS) and IEEE802.11 Wireless Local Area Network (WLAN) interfaces, connecting back to its corporate network N via a security gateway SGW through an Internet Protocol Security Protocol (IPSec) protected tunnel VPNT1 or VPNT2 across the insecure public Internet I. The mobile node MN might use the IPSec tunnel to access information within its corporate network or it might tunnel back all its external traffic to utilise the security services, for example a home firewall, offered by its corporate network security gateway SGW.
In the first instance, the mobile node MN roams into a foreign network FN1 where it is allocated or configures itself an IP address IP1 associated with its GPRS interface. The mobile node MN(IP1) and security gateway SGW engage in Internet Key Exchange (IKE) signalling to configure an IPSec tunnel VPNT1 through which data traffic can pass securely. This complex step involves the creation of an IKE Security Association (IKE SA) after the mobile node MN(IP1) and security gateway SGW have performed mutual authentication. The security association to form the IPSec tunnel (VPN connection) is created under the protection of the IKE SA.
Owing to mobility, the mobile node MN disconnects from the first foreign network FN1 and attaches itself (step s1) to a second foreign network FN2 where the mobile node MN is allocated or configures itself a new or additional IP address IP2 on its GPRS interface. Alternatively, mobility results in the mobile node MN coming under the coverage of both GPRS and WLAN in the second foreign network FN2 resulting in the mobile node MN simultaneously supporting both IP addresses IP1 and IP2 on its GPRS and WLAN interfaces respectively. In the first case, the mobile node MN wishes to maintain the VPN connection to the security gateway SGW irrespective of its changing IP address whereas in the second case, the mobile node MN wishes to use the most efficient available connection. In both cases, the mobile node MN may have to reform a VPN connection between the security gateway SGW and the second IP address IP2, a cumbersome process possibly requiring user interaction.
A new approach being investigated by the Internet Engineering Task Force (IETF) IKEv2 Mobility and Multi-homing (MOBIKE) Working Group is for the mobile node to use explicit signalling to inform the security gateway peer about the updated address of the mobile node and thereby effect the switching of the VPN connection from IP1 to IP2. This switching of VPN connections between IP addresses is effectively a re-direction of data intended for the mobile node. A problem with this approach is that it can be exploited to launch so-called “third party bombing” or denial of service (DoS) attacks whereby a valid peer re-directs its traffic to some third party with the intent of flooding the victim with large amounts of traffic.
The IKE security association between the mobile node and the security gateway protects the explicit MOBIKE signalling to inform the security gateway of the mobile node's new address such that the security gateway knows that the signalling has come from an authenticated source. However, the security gateway still needs to be assured that the IP address contained within the update signalling belongs to the mobile node and any subsequent re-direction to the new address will not result in a third party bombing attack.
As part of the MOBIKE protocol, it has been proposed to perform return routability (RR) tests to ensure that the mobile node is reachable at the claimed address carried within the MOBIKE update payload. The return routability tests are proposed to be along the lines of the dead-peer-detection (DPD) procedure whereby peers exchange empty informational packets. Appropriate modifications are required to ensure that the IKE SA is not deleted if the DPD test to an updated address fails.
There are several problems with the RR/DPD test. It is possible within the current IKEv2 DPD procedure for a real authenticated node that has turned malicious to reply to a DPD test packet without processing the request packet. An enhancement is required to DPD whereby the initiator has to insert a cookie or nonce tied to the claimed IP address that is returned by the IKE responder. IKEv2 implementations with window size of 1 will prohibit DPD tests whilst some other IKEv2 exchanges are ongoing. Additionally, RR/DPD could delay data re-direction owing to the round trip delay involved in executing the procedure.
It would be advantageous for the mobile node to have alternative mechanisms to assert ownership of claimed IP addresses to security gateways without incurring the signalling overhead of RR/DPD.